Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/859

Internet Message Format | 1994-08-27 | 4KB

Date: Tue, 19 Jul 1994 02:20:39 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Amodal Dialogs, etc.
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407190239.A15671-0100000@grad>
Mime-Version: 1.0
Precedence: bulk

Well, with all this discussion of amodal dialogs, etc., I have been
prompted to write my own.  At first, it was just to see if I could do it,
but I added it to a program I'd written and was very pleased with the
results.  There was discussion on Gem-list about how difficult it is to
handle sliders on some amodal dialog package or other.

So I decided to put code into my handler that would handle sliders with
the requirements that it should be as easy and transparent to the developer
as possible and placing as much information as possible in the resource
file, not the program source code.  After a little design work, I came up
with something I liked, but I figure it's probably not a new way of doing
it.

In the resource editor, you begin by creating a BOXTEXT object and put
into it 4 6-digit numbers corresponding to the following:
  1.  lowest value for result
  2.  highest value for result
  3.  current value
  4.  size of slider relative to high/low values and used for distance to
      page "up" or "down".
Plus a single character specifying:
  5.  '+' sign if slider physical size will be relative to (4) within range.
      Anything else will keep slider size constant at what is set in RSC
      file.
Assign to this object an extended object type of 1 for vertical or 6 for
horizontal.

On top of that (and obscuring it), you place a left/up button (extended
object type 3), a right/down button (type 4), and a slider box/frame (type
2).  On top of the box, place a slider (type 5).  NONE of the objects
should have any flags set (ie. do not make them touch-exit).  All objects
should have the same proper height or width, depending on orientation,
and they should all have a border size of -1.  Only the parent BOXTEXT
object need be given a name, unless the slider, for example, is a BOXTEXT
that displays a value.

For the program source code, there is little to worry about.  If the
slider position and size in the resource file do not correspond to the
numbers you placed in the parent BOXTEXT, then you can kick them into
place by calling a routine immediately after you initialize the dialog.

Whenever a slider event occurs, it is of no concern to the programmer what
button was pressed or whatever, so my routines return the object number of
the parent like any other button press elsewhere on the dialog so that the
programmer can pick the numbers out of the TEDINFO for that TEXTBOX at his
leisure.  The numbers are automatically maintained by my code, so you
need only retrieve the position, and can, if desired, leave the other
numbers as they were entered in the resource editor.


In addition to this, I decided that I wanted to keep the title of the
window stored in the resource file also.  When the dialog is initialized,
the object number of any object with a TEDINFO is passed to the service
routine and the title is retreived from there.


Tell me what you think.  Is this too complicated?  If so, what better way
do you suggest?  I intend to release my source code for use by Atari
developers, although I have not determined how I will handle
compensation.  (I could charge developers who use it a small one-time fee.)